(1) Field of the Invention
The present invention relates to a technique for generating an execution program from source programs written in an object-oriented language and executing the execution program.
(2) Description of Related Art
Currently, there are various program execution systems which generate execution programs by compiling and linking source programs that are written in programming languages by users. The generated execution programs are executed in computer-integrated systems such as mobile telephones, Set Top Boxes (STBs), televisions or the like, or executed in personal computers (hereinafter referred to as PCs).
The following is a description of a conventional program execution system that allows the computer-integrated systems to operate based on a source program written in Java (Java is a trade mark of Sun Microsystems), an object-oriented language.
The conventional program execution system is composed of a program generation apparatus and a terminal apparatus which is a computer-integrated system.
The program generation apparatus compiles (1) source programs of one user class, and (2) programs stored in base libraries provided for different terminal apparatuses, and links the programs to generate a different light-weight user class file for each terminal apparatus. Here, the base library includes a group of files which constitute a program that depends on a terminal apparatus and is directly related to control of hardware units inherent in the terminal apparatus, such as a program for controlling the data communications or display on a display unit.
The light-weight user class file generated for each terminal apparatus is stored in the terminal apparatus, and each terminal apparatus operates according to its own user class file.
Now, the conventional program execution system will be described in detail using two types of terminal apparatuses A and B which differ from each other in terms of a part of the hardware construction. Here, it is supposed that light-weight user class files are generated from source programs of the same user class, and that the generated user class files are executed in the corresponding terminal apparatuses.
FIGS. 1 and 2 show examples of source programs written in Java from which base class files that respectively allow the terminal apparatuses A and B perform the same process is generated. FIG. 3 shows an example of a source program written in Java from which a user class file that is used by the terminal apparatuses A and B in common is generated. It should be noted here that in these figures, only field definitions are shown, and descriptions related to detailed use of these fields in methods are omitted.
As shown in FIG. 1, the class Built_in_classX includes instance fields “privateX1”, “privateX2”, and “privateX3” and instance fields “fieldX1” and “fieldX2”. The instance fields “privateX1”, “privateX2”, and “privateX3” each include a modifier “private”, which indicates that accesses from methods included in other classes are prohibited. The instance fields “fieldX1” and “fieldX2” can be accessed from other classes.
Also, the class Built_in_classY includes instance fields “privateY1” and “privateY2” and instance fields “fieldY1”, “fieldY1”, “fieldY2”, and “fieldY3”. Since the instance fields “privateY1” and “privateY2” have a modifier “private”, accesses from methods included in other classes to these instance fields are prohibited. The instance fields “fieldY1”, “fieldY2”, and “fieldY3” can be accessed from other classes.
The class Built_in_classX shown in FIG. 2 includes (1) instance field “privateX1” which cannot be accessed from methods included in other classes and (2) instance fields “fieldX1” and “fieldX2” which can be accessed from other classes. Also, the class Built_in_classY shown in FIG. 2 includes (1) instance field “privateY1”, “privateY2”, and “privateY3” which cannot be accessed from methods included in other classes and (2) instance fields “fieldY1”, “fieldY2”, and “fieldY3” which can be accessed from other classes.
In each of the above source programs, the class Built_in_classX is inherited by the class Built_in_classY, and the class Built_in_classY is inherited by the class User_class.
For each of the terminal apparatuses A and B, a class Built_in_classX and a class Built_in_classY are compiled to generate one base class file.
As understood from above, both terminal apparatuses A and B use a class Built_in_classX and a class Built_in_classY which provide the same function for either of the terminal apparatuses A and B, respectively. The instance fields used in both the two classes, such as “fieldX1”, “fieldX2”, “fieldY1”, “fieldY2”, and “fieldY3” can be accessed by other classes and provide the same contents for either of the class Built_in_classX and class Built_in_classY.
The two classes also include a different number of instance fields that include different contents and cannot be accessed from other classes. For example, the class Built_in_classX for terminal apparatus A uses “privateX1”, “privateX2”, and “privateX3”; and the class Built_in_classX for terminal apparatus B uses only “privateX1”.
Note here that the “privateX1”s for terminal apparatuses A and B have the same name but different contents. This also applies to the “privateYl”s and “privateY2”s.
The instance fields “privateX1”, “privateX2”, “privateX3”, “privateY1”, and “privateY2” for terminal apparatus A and the instance fields “privateX1”, “privateY1”, “privateY2”, and “privateY3” for terminal apparatus B are defined with the modifier “private”, are used to exercise control according to the hardware of each of the terminal apparatuses A and B, and depend on the base class design of the terminal apparatus. Hereinafter, these instance fields are therefore referred to as class-design-dependent fields.
The other instance fields “fieldX1”, “fieldX2”, “fieldY1”, “fieldY2”, and “fieldY3” commonly used by the terminal apparatuses A and B are used to exercise control common to the terminal apparatuses A and B, and are not dependent on the base class design of the terminal apparatus. Hereinafter, these instance fields are referred to as class-design-non-dependent fields.
A class User_class is compiled to become a user class file. As shown in FIG. 3, the class User_class uses instance fields “fieldU1” and “fieldU2”.
FIGS. 4 to 7 shows instance field offset tables of the above class Built_in_classXs, class Built_in_classYs, and class User_class. Each instance field offset table includes unique numbers assigned to the instance fields by the conventional program generation apparatus.
FIGS. 4 and 5 show instance field offset tables for base class files. FIGS. 6 and 7 show instance field offset tables for user class files. FIGS. 4 and 6 correspond to the terminal apparatus A, and FIGS. 5 and 7 correspond to the terminal apparatus B.
As shown in FIGS. 4 and 5, the instance field offset tables of the class Built_in_classYs include the instance fields inherited from the class Built_in_classXs, with the same offset numbers assigned. More specifically, for the terminal apparatus A, the same offset numbers as the class Built_in_classX are assigned to the instance fields “fieldX1”, “fieldX2”, “privateX1”, “privateX2”, and “privateX3”; and for the terminal apparatus B, the same offset numbers as the class Built_in_classX are assigned to the instance fields “fieldX1”, “fieldX2”, and “privateX1”.
As shown in FIGS. 6 and 7, the instance field offset tables of the classes “User_class” include the instance fields inherited from the class Built_in_classYs, with the same offset numbers assigned. More specifically, for the terminal apparatus A, the same offset numbers as the class Built_in_classY are assigned to the instance fields “fieldX1”, “fieldX2”, “privateX1”, “privateX2”, “privateX3”, “fieldY1”, “fieldY2”, “fieldY3”, “privateY1”, and “privateY2”. This also applies to the terminal apparatus B.
As shown in FIG. 6, in the instance field offset table for the terminal apparatus A, offset numbers “11” and “12” are assigned to the instance fields “fieldU1” and “fieldU2”, while as shown in FIG. 7, in the instance field offset table for the terminal apparatus B, offset numbers “10” and “11” are assigned to the instance fields “fieldU1” and “fieldU2”.
The program generation apparatus modifies each class file according to the instance field offset tables. More specifically, instance field names used as operands in the instructions included in each class file are replaced with the corresponding offset numbers, and identification information corresponding to the instance fields are deleted from the constant pool in the class file. In this way, a different light-weight user class file is generated for each terminal apparatus from source programs of the same user class.
The conventional program execution system, however, needs to link as many times as there are types of terminal apparatuses (i.e., types of light-weight base classes) even if source programs of the same user class are used.